Student Merge

Utilities > Student Merge

The Student Merge utility merges two student accounts together in case of duplication.

Screenshot of the Student Merge screen as described on this page.

  1. Primary Student - select primary student record

  2. Duplicate Student(s) - select duplicate student record(s)

  3. Update - click to run merge; verify by clicking Yes or cancel by clicking No

  4. Reset - click to reset to defaults

Merge Details

The following data will be merged:

  • First, Middle, Last Name, and Suffix

  • State Identifier

  • Email

  • Cell Phone

  • Home Phone

  • Do Not Call

  • Do Not Email

  • SSN

  • Date of Birth

  • Gender

  • Ethnicity

  • Race

  • Allergies

  • Dietary Restrictions

  • Religious Restrictions

  • Refused Benefits

  • Student Notes

  • Student Tags

  • Person Attachments

  • Person Notifications

  • Person No Buy Items

  • Picture

    • If the Primary Student has no picture and the Duplicate Student does, then we move the picture to the Primary Student.

    • If the Primary Student has a picture and the Duplicate Student has a picture, then we ignore the duplicate and leave the Primary Student picture as is.

  • Transactions

    • All transactions will be merged (including transactions from the online store). Any account transactions that were showing for the Duplicate Student, will now show on the Primary Student.

    • Transactions will only be merged for the months that are not locked out.

  • LINQ Connect Account

    • When Primary doesn't have a LINQ Connect account, but Duplicate does, then change the LINQ Connect account to be linked to the Primary student.

    • When both Primary and Duplicate students have LINQ Connect accounts, keep them both linked as they are, but display the merged Duplicate Student's LINQ Connect transactions in the Primary Student's account (as that should merge over.)

  • Meal Applications

    • If the Duplicate Student has an existing application that was processed and the Primary Student does not, then we correct the student’s name on the existing application on the backend. If a student has overlapping meal applications, then we will not touch those applications and they will NOT be merged.

    • If a student has an application with pricing under one eligibility status but has transactions being rung up with different pricing under another eligibility status, then the nightly process will resell those meals.

Example: John has an application with an eligibility status of Free, but his transactions were being rung up under Johnny with an eligibility status of Paid. John should have been receiving free meals the whole time.

Applications that are selected for Verification CANNOT and will not be merged.